Transmission control protocol (TCP) is the dominant protocol in use today on the Internet. TCP is carried by Internet protocol (IP) and is used in a variety of applications including reliable file transfer and Internet web browser applications. The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) are cryptographic protocols designed to provide communications security over public networks, such as the Internet. The SSL protocol is the dominant protocol for secure network communications, such as secure communications over the Internet. The main function of the SSL protocol is to provide privacy, security and reliability between two communicating applications. Privacy and security are provided through connection encryption and identity authentication based on certificates, while reliability is provided via dependable maintenance of a secure connection through message integrity checking. As such, the SSL protocol involves intensive messaging to set up and maintain the connection or session.
The Internet Engineering Task Force (IETF) created the TLS protocol in an attempt to standardize SSL within the Internet community. The TLS protocol was designed to facilitate client/server applications to securely communicate in a way to prevent eavesdropping, tampering or message forgery. Similar to SSL, the TLS protocol requires the initial setup of a TLS connection or session between the client and server. More specifically, once the client and server have agreed to use TLS, they negotiate a stateful connection by using a handshaking procedure, during which the client and server agree on various parameters used to establish the connection's security. Accordingly, as with SSL, the TLS protocol involves intensive messaging and handshaking to set up and maintain the connection or session.
The Hypertext Transfer Protocol (HTTP) is an application layer protocol for distributed, collaborative, hypermedia information sessions, which serves as the foundation for application layer data communications over the Internet. Hypertext is structured text that uses logical links (hyperlinks) between nodes containing, and HTTP serves as the protocol to exchange or transfer hypertext. Hypertext Transfer Protocol Secure (HTTPS) is the communications protocol for secure communication using the HTTP protocol. HTTPS consists of the layering of HTTP on top of the SSL/TLS protocol, thereby adding the security capabilities of SSL/TLS to standard HTTP communications. The security of HTTPS thus consists of that of the underlying TLS, which uses long-term public and secret keys to exchange a short term session key to encrypt the data flow between client and server. In view of the intensive setup, maintenance and key messaging of the TCP, SSL/TLS and HTTP/HTTPS protocols, these protocols can suffer from significant performance degradation in a high latency network (e.g., a long fat network (LFN), such as a satellite network). For example, in an LFN, TCP throughput degrades because of TCP congestion control, SSL/TLS suffers from high session setup delay, and HTTP has high idle time between a request and a response.
A typical LFN is the satellite network, which provides high link capacity, but exhibits large messaging latency because of the long travel of signals between a ground terminal and a satellite orbit (e.g., a geostationary orbit). As a result of the long distance from a ground terminal to a satellite in a geostationary orbit, a typical geosynchronous satellite network has a high propagation delay between a user terminal (e.g., Very Small Aperture Terminal (VSAT)) and the central satellite gateway (e.g., about 240-270 ms propagation delay for a one way trip to/from the satellite). Thus a typical round trip time (RTT) for such a network is upwards of 480-540 ms. Further, upstream channels of a satellite system are shared by many VSATs, and thus suffer from access contention. To resolve network contention of upstream medium among VSATs and enhance quality-of-service, Bandwidth-on-Demand (BoD) algorithms are typically employed for network resource allocation in satellite networks. When a VSAT unit receives packets from a client, it provides a corresponding bandwidth request from a network control center (NOC) or gateway, and the NOC responds with an allocation of channel slots to fulfill the bandwidth request. The negotiation back and forth between the VSAT and the NOC thereby add additional RTTs to the communications process. Thus, it takes at least three propagation delays (720-810 ms) to send a packet from VSAT to the gateway.
To overcome TCP throughput degradation in LFNs, performance-enhancing proxies (PEP) were developed and have been in use for over a decade now. See, e.g., J. Border et al., “Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations,” IETF RFC 3135, June 2001. In some broadband satellite networks, PEP may be the core network function. In satellite networks, PEP proxies may be located at both the satellite gateway and user terminal remote sites, allowing for TCP senders to quickly fill up the high capacity link. The transport layer PEP (e.g., TCP PEP), for example, in the gateway spoofs acknowledgment messaging (ACKs) to reduce waiting time for ACKs at the sender, and uses large window size to fill up the link. Further, HTTP is based on a request and response process (e.g., a web page request and web page content response). With a high propagation delay link (e.g., a satellite link), the request-response process causes large delays in web page loading. To resolve such latency issues in LFNs, HTTP prefetching mechanisms have long been employed. For example, before the web browser even requests the embedded objects of a website, an HTTP proxy server in the gateway anticipates such requests by parsing the HTML pages, prefetching the embedded objects, and pushes them to an HTTP proxy client at the user satellite terminal. By serving the cached objects at the satellite terminal, the response time is reduced. Even though an LFN works relatively well with web browsing using TCP PEP and HTTP prefetching, latency issues still exist when accessing secure websites. Most secure websites (e.g., ecommerce websites and web email sites provide channel security by using HTTP over SSL/TLS (HTTPS). With HTTPS, because the web contents are encrypted, the HTTP proxy server cannot read and parse the encrypted web contents. Thus, the HTTP prefetching mechanism cannot be used for secure websites. In addition, SSL/TLS introduces additional delay for the session setup. Full SSL/TLS session setup requires two round-trip times (RTTs), which introduce significant latency and other issues in LFNs.
Other approaches have been developed to resolve the performance degradation of SSL traffic over satellite networks. Pursuant to one such approach (SSL Bridging—see, e.g., U.S. Pat. No. 7,584,500) proxy servers operate as a distributed HTTP proxy servers with HTTPS capabilities, whereby the proxy servers maintain SSL protection of communications between the browser and the server, and pre-fetch secure documents via rewritten secure content requests. More specifically, SSL Bridging is based on the split of one end-to-end SSL session into three sessions: one session between a client and a proxy at VSAT, another session between a proxy at VSAT and a proxy at satellite IP gateway, and the last session between a proxy at the IP gateway and a web server. Since a proxy at the gateway creates a SSL session to a web server, it can decrypt the web objects and parse the HTML file, and can thus perform HTTP prefetching at the gateway. Using this approach, however, third-parties (e.g., satellite Internet service providers) have access to the secure data, and thus SSL bridging is not an acceptable approach for providing end-to-end security.
Another approach (Dual-Mode SSL or DSSL—see, e.g., A. Roy-Chowdhury et al., “Security Issues in Hybrid Networks with a Satellite Component,” IEEE Wireless Communications, December 2005) is based on dual-mode encryption of web pages. Pursuant to this approach, the secure connection has two modes—an end-to-end main mode connection between the client and the web server, and a secondary mode connection that has the hub HTTP proxy as an intermediate node. A client and a web server have two keys (K1 and K2) for encryption, but the proxies at the user terminal and the gateway have only one key (K2). The key K1 is used to encrypt the whole web page and the key K2 is used to encrypt the embedded object links of the page. Thus, web servers need to insert two data elements: object links and web page. The proxy at the gateway can parse the object links using the key K2, so it can pre-request the objects. Accordingly, however, the DSSL approach is more complex in comparison to SSL in that it requires the creation of an additional connection and thus involves additional overhead in establishing and maintaining that connection. Further, web servers parse the HTML file and parse object links and the third-party (e.g., the proxy at the gateway) can read the object links, and thus DSSL similarly cannot provide full end-to-end security.
Pursuant to a further approach (Multipath TCP or MPTCP—see, e.g., Ford et al., “TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC-6824, January 2013), a single TCP streaming session is provided over multiple paths or links (as used herein, the terms “path” or “paths” and “link” or “links” are used interchangeably). More specifically, a Multipath TCP connection provides a bidirectional byte-stream between two hosts communicating like normal TCP, while enabling the hosts to use different paths with different IP addresses to exchange packets belonging to the MPTCP connection. At the network layer, each MPTCP sub-flow looks like a regular TCP flow whose segments carry a new TCP option type, whereby a new TCP option is used for connection ID, sequence numbers and ACK numbers of sub-flows. MPTCP provides a benefit in reliability and higher throughput, however, it may present compatibility issues with middle-boxes or proxies. Such middle-boxes may rewrite TCP headers and drop unknown TCP options (See, e.g., Raiciu et al., “How Hard Can it Be? Designing and Implementing a Deployable Multipath TCP,” Proceedings of NSDI, San Jose, Calif., April 2012). For example, PEP terminates TCP connections, and thus MPTCP would not be compatible with PEP proxies. Even though PEP forwards the MPTCP option, if the PEP proxy does not implement the MPTCP functionality (e.g., does not provide for MPTCP Data ACKs), the connection will be broken.
Multi-Connection TCP (MCTCP—see, e.g., Scharf, “Multi-Connection TCP (MCTCP) Transport, IETF Internet-draft, July-2010) and Payload Multi-Connection Transport (PLMT—see, e.g., Singh et al, Payload Multi-Connection Transport Using Multiple Addresses,” IETF Internet-draft, August 2010) provide other versions of MPTCP, whereby, instead of TCP option, they use a shim layer (between the transport layer and the application layer) to insert multipath flow information. MCTCP, however, also uses the TCP option for TCP handshakes to create the multipath connections, and thus presents the same potential incompatibility issues with middleboxes. Further, both MCTCP and PLMT require additional connections for multi-connection modes, which increase overhead for the setup and maintenance of such additional connections. The additional connections are critical in LFNs, especially in satellite networks whose RTT can be more than 700 ms. Because of these additional connections for each flow, they are not useful for short TCP flows.
Hybrid satellite-terrestrial networks have also been developed (See, e.g., Arora et al., “Asymmetric Internet Access Over Satellite-Terrestrial Networks,” Proceedings of the AIAA International Communications Satellite Systems Conference, February 1996). Pursuant to such a hybrid network, a hybrid terminal provides two network interfaces, with one being for connection to a receive-only satellite terminal and the other being for an outgoing connection to a terrestrial modem. This hybrid approach delivers all upload or inroute traffic through the modem/terrestrial network and receives all download or outroute traffic through the satellite network. Because of the fixed paths for each direction, however, this system presents performance issue and large data usage of terrestrial networks. For example, some session setup messages (such as SSL server hello messages) are delivered through the satellite network resulting in longer session setup delays. Further, the terrestrial network suffers from large data usage (at a corresponding high expense) with large upload files. Additionally, the hybrid system uses IP tunneling, which is incompatible with splitting a flow into two paths (e.g., a sequence number and ACK number hole issue arises with such split flows).
What is needed, therefore, are approaches for application aware multihoming with multipath tunneling protocols to address network protocol performance and data throughput degradation in long fat networks (LFNs), and particularly in the case of secure network protocols and data throughput over secure network sessions.